Motivation

The microfrontend e2e test microfrontend > RUM > with beforeSend > expose handling stack for fetch requests › async fails ~70% of the time on firefox-pinned (10 failed / 6 flaky / 4 passed out of 20 reproductions). The same race affects any fetch resource event in production: event.context.handlingStack (and the rest of the request-derived domain context — requestInit, response, error, …) is intermittently undefined for fetch resources on Firefox.

Root cause

When a fetch resolves, two things happen around the same time:

• the browser dispatches a PerformanceResourceTiming entry to our observer
• afterSend() resumes from await responsePromise and notifies REQUEST_COMPLETED

On Firefox the observer task can fire before the resolve microtask runs, so the request isn't in the requestRegistry yet when assembleResource() looks it up via requestRegistry.getMatchingRequest(). The lookup returns undefined and the resulting resource event is missing all request-derived domain context.

This was introduced by #4285 always collect early requests (commit 2b71062e7), which switched from request-driven (performance.getEntriesByName() at REQUEST_COMPLETED time) to entry-driven matching.

CI logs of the failing case make the ordering obvious:

[failure run]
[DEBUG resourceCollection assembleResource]
  entryStartTime:90, matchedRequest:null, registrySnapshot:[]   ← runs first, registry empty
[DEBUG requestRegistry REQUEST_COMPLETED]
  url:.../ok, startRel:89, hasHandlingStack:true, nowRel:121     ← arrives too late

Changes

• startResourceCollection: for request-type entries (fetch / xmlhttprequest initiator), defer the registry lookup by REQUEST_MATCHING_DELAY (50 ms) via setTimeout. In practice the matching REQUEST_COMPLETED arrives within ~30 ms even on slow CI runners, so 50 ms is a generous bound.
• assembleResource now takes the resolved request directly instead of pulling it from the registry — the matching policy is owned by the call site where the timing context is clear.
• requestRegistry is unchanged; getMatchingRequest is still synchronous.
• Unit tests drive the new delay through mockClock.tick(REQUEST_MATCHING_DELAY) inside runTasks.

Test instructions

Repro on the e2e suite (Firefox is the most reliable, but the race is browser-agnostic):

yarn playwright test --config test/e2e/playwright.config.ts --project firefox-pinned \
  --repeat-each=20 \
  -g 'microfrontend RUM with beforeSend expose handling stack for fetch requests async'

CI validation (e2e job scoped to the failing test, --repeat-each=20):

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.
• Updated documentation and/or relevant AGENTS.md file